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ABSTRACT 


Tt L 3 document  presents  an  overall  general.  description 
for  tin  National  Military  Coneand  Systea  Information 
Processing  Systee  360  Poreatted  Pile  System  (commonly 
referred  to  as  NIPS  or  NIPS  360  PPS)  an  advanced  data 
management  system  which  is  operational  oi  IBM  System/360  and 
Syst  = m/370  computers.  It  describes  the  capabilities  of  the 
components  which  comprise  the  systea:  File  Structure  (PS) 
ile  Maintenance  (?  M)  , Pile  Revision  (PR),  Retrieval  an 
ort  Processor  (RASP),  Output  Processor  (OP),  Quick  Inguiry 
Processor  (QUIP),  source  Data  Automation  (SODA),  Online 
Source  Edit  (El II),  Terminal  Processing  (IP)  and  Utility 

Support  (UT). 

This  document  supersedes  CSS  GD  15-68. 
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3ENEPAL  DESCRIPTION 


Section  1 

I HP  RO DUCT  ION 


The  NIPS  360  PFS  is  an  advinced  data  management  system 
proviiLjg  powerful,  efficient,  and  flexible  da*a  nanaqenent 
support  to  a wide  variety  of  aaers.  HIPS  provides  the 
abiLity  to  structure  files,  generate  and  Maintain  files, 
retrieve  infornation  and  output  that  information  in  sinple 
or  roiplex  arrays  on  a variety  of  output  devices.  Seven 
major  processing  functions  are  provide!: 

1.  File  Definition  (structure) 

2.  File  Generation  and  Naintenance 

3.  File  Revision 

'4.  Data  Selection  and  Ordering  (retrieval) 

5.  Foraal  Report  generation  (outputi 

6.  Tereinal  Processing  and  Display 

7.  UtiLity  programs  supporting  table  generation, 
subroutine  loading  and  data  conversion,  among 
other  s . 

8.  Data  Selection  and  Report  Generation  from  non- 
NIP5  data  files. 

N I? 5 functions  under  the  Primary  Control  Program  (PCP)  , 
t.i  a ■ ul  tipro  grama  in  g with  fixed  number  of  tasks  (HFT)  or  the 
aul ti programming  with  variable  number  of  tasks  (HVT) 
versions  of  the  I3M  System/360  Operating  System.  NIPS  al30 
functiois  under  IBM  system/370  System  Control  Programming 
3p  ? racing  System /virtual  Storage  1 (VSl)  and  Operating 
System/virtual  Storage  2 (VS2) . Using  multiprogramming 

capabilities,  NIP5  permits  online  functions  to  parallel  the 
normal  background  or  batched  processing  functions.  NIPS  can 
UR*  a broad  raige  of  hardware  since  input/output  device 
in  Impendence  has  been  retained.  Core  sizes  are  relatively 
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noncritical  in  that  NIPS  will  function  within  90K  of  core 
uiary.  Core  usage  is  dynanic,  permitting  NIPS  to  aa  ke 
aatimua  use  of  the  partition  or  region  of  core  provided  by 
the  operating  systea.  Minimum  core  requirements  for  NIPS 
anl  tie  operating  systea  are  128K  for  single  partition 
systems  and  256K  for  multitasking  systems  using  the  online 
caoabilities.  The  design  base  was  a S/360  Model  50H; 
however  the  instruction  set  utilization  was  limited  to  the 
standard  instruction  set  and  the  decimal  feature 
i nst  r uctions. 

MP3  will  support  data  files  organized  with  the  Indexed 
Sejuontial  Access  Method  (ISAM),  resident  on  a direct  access 
stjrige  device  (such  as  an  IBM  3330,  23^4  or  2311  Disk 
St  nr  ige  Device),  and  the  Sequantial  Access  Method  (SAM), 
rasident  on  tape  or  direct  access  devices.  when  installed 
on  S/370  with  OS/V5 , NIPS  will  support  data  f’les  organized 
ur.  ler  the  Virtual  Storage  Access  Method  (VSAM)  for  batch 
pr j; ?s5iig. 
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Section  2 


PILE  CONCEPTS 


As  Lo  lost  generalized  systems,  HIPS  is  designed  to 
perai4-  nonprogrammers  to  specify  data  structures  inquired  to 
support  a job  funct  ion-  This  is  done  by  a simple, 
meaningful  language  convenient  to  the  user.  The  system 
perfons  exhaustive  diagnostics  and  grants  a high  degree  of 
independence  from  the  physical  storage  of  da4a,  although 
users  i u 3 1 be  aware  of  the  logical  relationships  between 
data  eleaents.  Teras  used  in  this  text  are  defined  as 
f ' Hows: 

Data  base  - A collection  of  data,  supporting  tha 

general  mission  or  function  of  the 
installation.  It  is  typically  com- 
posed of  nany  different  logical  data 
3ets  (coaaonly  called  files). 

Data  file  - A logical  set  of  data  elements,  - . c:  t 

into  associated  arrays  called  lecords. 

Data  file  records-  That  collection  of  data  eleaents  iden- 
tifiable by  a unique  data  value  or  Key. 

A single  data  elaaent. 

^aLci  pi b ility  to  index,  or  access, 
the"contents  of  a data  file  by  a 
■ei  ns  other  than  the  record  identifi  r. 
The  index  data  set  is  a logical  data 
set  of  all  index  values  and  the  data  file 
records  associated  with  each. 

Pita  ^roveriig  a broad  spectrua  of  ^subjects  may  be 
r -iiv?l  by  an  installation  in  varied  foras  and  from  many 
3'  ires.  This  data  is  categorized  by  subject  and  added  to 
t :oll»rtLor  of  siailarly  categorized  data  called  a data 
f:L*.  To  aid  in  placing  each  element  of  data  into  the  file, 
ii 1 subsequently  retrieving  it,  the  files  have  a definite 
structure  pattern  called  the  file  foraat.  The  file  format 


^ Field 

Second ary/k ey- 
wori  indexing 
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is  desiqned  to  group  similar  data;  i.e.,  description  of  an 
activity,  event,  person,  or  thing.  Each  of  these  groups  is 
called  a file  record.  Thus,  a formatted  file  is  an  ordered 
collection  of  file  records,  each  of  which  contains  data 
arranged  according  to  a previously  established  file  forat. 
In  *IPS,  the  field  is  the  smallest  naeed  entity  processed. 
By  use  of  a capability  called  partial-field  notation,  a user 
nay  refer  to  part  of  a field.  However,  direct  reference  in 
the  siipLest  fora  defines  field  as  the  lowest-level  elenent 
of  a file  record.  The  system  provides  for  grouping 
contiguous  fields  in  the  record  and  defining  a name  for  the 
r^sultait  string.  These  composite,  concatenated  fields  are 
called  groups  in  NIPS  terminology.  Nesting  of  definitions 
(groups  of  groups  of  groups)  is  permitted  and  is  effectively 
unlimited  in  depth  of  the  resultant  array.  Data  file 
records,  therefore,  may  be  defined  as  logical  collections  of 
f Lelds  and/or  groups. 

It  is  almost  always  necessary  to  carry  both  repetitive 
ani  -joarepetitive  information  in  a file  record;  NIPS 
provides  for  this  need  (figure  1).  Data  that  occurs  only 
or.ce  per  record  is  called  fixed  data.  The  data  elements  are 
t- raed  fixed  fields.  A definable  data  pattern  that  recurs 
periodically  within  a record  is  called  periodic  data.  Such 
fields  are  therefore  termed  periodic  fields.  Collections  of 
field  strings  having  the  sane  format  are  called  sets. 
Therefore,  the  string  of  fields  containing  nonr epetitive 
data  in  a file  record  m y be  defined  as  the  fixed  set.  A 
maximum  of  100  fields  may  be  defined  in  a fixed  set. 
Periodic  fields,  grouped  and  recurring  as  strings,  are 
termed  pariodic  sets,  while  one  string  of  such  a set  is 
c tiled  a periodic  subset.  Op  to  255  different  periodic  sets 
containing  up  to  100  fields  each  may  be  defined. 

NIPS  provides  stcuctjres  composed  of  4 master  segment  or 
fixed  set,  with  one  level  of  subordination  it he  periodic  set 
or  sets).  The  foraat  of  a fixed  set  is  constant  throughout 
th 3 file.  More  than  one  periodic  set  may  be  defined  in  the 
file  structure,  but  as  in  the  case  of  the  fixed  set,  the 
format  is  constant  throughout  the  file  on  a set-by-set 
basis.  In  other  words,  the  foraat  of  the  first  Aperiodic  set 
in  eari  record  is  t<he  sane,  and  the  format  of  the  second 
■riodic  set  in  each  record  is  the  saee.  This  is  valid  for 
rich  record  of  the  file.  Formats  of  Periodic  Set  1 and 
Periodic  Set  2,  however,  need  not  be  the  saee. 
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The  system  provides  two  other  types  of  data  storage. 
Pirst,  the  user  eay  include  a variable  field  within  the 
definition  of  each  of  his  fixei  or  periodic  sets.  As  the 
name  implies,  this  field  can  contain  variable  length 
character  strings  and  is  include!  in  physical  storage  only 
whan  there  is  actual  data  in  the  field.  Second,  the  user 
nay  cause  the  systen  to  structure  several  variable  sets. 
Each  variable  set  contains  a variable  length  character 
string  and  exists  only  whea  data  is  present.  The  principal 
difference  between  the  variable  field  and  the  variable  set 
i.-»  in  ♦■heir  association  with  other  data  elements.  The  data 
in  a variable  field  is  specifically  associated  with  the  data 
Lr  a fixed  set  or  a single  periodic  subset.  Data  in  a 
variable  set  is  a logical  collection  associated  with,  bat 
subordinate  to,  the  fixed  set.  The  only  relationship  it  has 
with  periodic  data  is  that  of  a coimn  parent  fixed  set. 
Data  nay  be  added  to  or  deleted  from  the  variable  set. 
Retrieval  of  records  based  on  the  content  of  variable  data 
fields  may  be  performed  by  either  executing  a scan  of  the 
field  for  the  qualifying  value  ( s)  or  by  employing  the 
keyword  Lad^xing  capability.  There  is  no  limitation  as  to 
the  length  of  a variable  set. 

Secondary  and  keyword  indexing  are  optional  capabilities 
available  to  enable  a user  to  have  more  flexible  control 
over  iLs  data.  A file  index  serves  essentially  the  same 
purpose  as  an  index  for  a book.  Given  an  abbreviated 
subject  or  topic,  a book  index  lists  all  pages  referencing 
that  i-opic.  Given  a field  value,  a file  index  lists  all 
data  racords  cbntaining  that  value.  The  purpose  of  such 
iidaxinq  is  to  reduce  the  time  required  to  query  a file.  It 
doas  this  by  checking  file  index  values  specified  by  a query 
to  determine  which  records  must  be  examined  in  detail  to 
satisfy  the  search  parameters.  Only  these  records  rather 
than  the  entire  data  file  are  searched.  Secondary  indexing 
is  the  method  far  specifying  fixed-length  fields  as  indexes 
ar  1 retrieving  records  based  on  the  contents  of  those 
fields.  Keyword  indexing  is  the  method  for  specifying 
variable  fields,  variable  sets  and  fixed-length  fields  as 
ini  axes;  selecting  values  from  the  field  as  keywords,  and; 
retrieving  records  based  on  the  presence  of  the  keywords 
witiin  the  queried  fields. 
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Figure  1.  NIPS  360  FFS  Data  P.ccord  Organization 
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Data  files  which  hare  been  created  by  other  data 
■anageeent  systees  or  by  special  purpose  programs  can  be 
pocassed  by  NIPS  for  data  retrieval  and  report  generation. 
This  is  a basic  capability  intended  only  as  an  initial  aid 
ir  examining  aon-NIPS  data  files.  To  use  the  full 
capabilities  of  NIPS  these  data  files  should  be  converted  to 
a standard  NIPS  data  file. 


I 
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Section  3 


SYS TEH  ORGAN IZ  ATION 


The  six  aajor  processing  c on pones ts  and  the  general 
utility  coapooejt  each  perforn  a general  task  and  are 

associated  with  a general  class  of  functions  to  be 
perf  oriel. 

The  File  Structuring  (FS),  File  Revision  (?R)  , and  File 
1 aint  enance  (FH)  conponents  ire  prinarily  concerned  with  the 
cieation,  reorganization  and  naint enance  of  the  systen 
files.  The  Retrieval  and  Sort  Processor  (RASP)  is  the 

priiary  information  retrieval  tool  while  the  Output 

Processor  (OP)  conponent  provides  for  fornal  report 
production.  Finally,  the  Terninal  Processing  (TP)  conponent 
pro  vidas  online  NIPS  progranaing,  file  interrogation, 
maintenance,  and  output  ca  pa  Dili  ties  through  a variety  of 
local  and  renote  terninals.  These  include  the  IBH  3277, 
2 ’50,  2250  and  2265  display  terninals,  the  IBH  1050  dial-up 

and  T B1  2741  teriinal3.  Bach  conponent,  as  welL  as  the 

utility  component,  is  discussed  briefly  in  this  section. 

, The  applicability  of  this  systen  to  a specific  task  area  can 

only  be  evaluated  at  the  detailed  level.  This  description, 
therefore,  suggests  only  in  the  nost  general  terns  the  trae 
d-*pth  of  the  actual  software  systen. 

3.1  File  Structure 

This  systen  conponent  pernits  the  user  to  identify  his 
dita  file  and  its  security  classification  and  to  introduce 
d'finitions  of  the  fields,  groups,  and  sets  that  are  to  sake 
up  nis  data  file.  Although  there  is  theoretically  no  Unit 
to  the  number  of  unique  data  elements  that  can  be  named  in 
a single  file,  the  systen  imposes  a practical  Unit  of 
approximately  25,000  names.  Structures  are  United  to  a 
s nila  level  of  subordination.  At  that  level,  however,  up 
t > 255  different  periodic  and/or  variable  sets  nay  be 

specified. 
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There  are  also  size  restrictions  in  the  length  of  a 
sLijls  periodic  subset  or  fixed  set.  This  constraint  is 
1,000  bytes  in  the  current  design. 

File  records  (the  collection  of  the  fixed,  periodic,  and 
variable  sets  which  are  uniquely  identified  by  a record 
identifier  or  key)  are  less  easily  defined  as  to  size.  The 
system  performs  dynamically,  giving  the  user  a high  degree 
of  flexibility.  As  a worst-case  condition,  the  system  mi y 
limit  the  user  to  99,000  bytes  per  file  record.  However, 
the  system  loads  into  memory  only  those  sets  referenced  by 
the  job,  thereby  effectively  permitting  a significant 
expansion  of  record  size. 

During  the  file  definition  process,  the  user  may  desire 
to  specify  in  advance  certain  automatic  functions  such  as 
conv?rsloi  of  retrieval  literals  to  coded  file  values, 
output  data  conversions  or  editing.  If  file  indexing  is 
desirel,  the  user  indicates  which  field  or  fields  will 
provide  the  index  values.  The  FS  component  provides 
mechanisms  for  this  purpose  and  records  these 
characteristics  in  the  basic  Pile  Format  Table  (PFT) . 

Record  control  or  key  fields  may  be  defined  as  a single 

field  or  a string  of  multiple  fields.  The  only  limitation 

is  that  the  total  record  control  group  may  not  exceed  244 

characters.  Periodic  subsets  may  also  have  data  fields  j 

assigned  for  seguencing  and  control  within  the  record.  If 

the  user  does  not  desire  to  provide  these  subset  control 

elements,  the  system  will  create  sequence  numbers  for  the 

control  function  and  will  maintain  then  as  a normal  part  of  ! 

the  FM  function. 

i 

FS  provides  a simple,  convenient  way  for  the  user  to 
specify  his  file  format  and  requirements.  Using  a simple 
free-fornat  language  which  uses  default  options,  the  user 
can  specify  the  Logical  data  associations  he  desires. 

Additional  limitations  to  the  FS  component  are  as 
follows: 

o A laxieue  of  50  subroutines/tables  may  be 
defined  for  a file. 

o A naximua  of  50  edit  aasks  may  be  defined,  ! 

each  not  eore  than  59  characters,  and  the 
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agqregate  total  of  edit  characters  aust  not 
exceed  1,000. 

o A total  of  100  fields  or  groups  aaj  be  define! 
for  each  set. 

o A naxinun  of  99  fields  nay  be  defined  in  a 

group . 

o A naxinun  of  50  groups  nay  be  defined  in  a 

set  . 

o Coordinate  fields  nay  consist  of  5,  6,  7,  fl, 

11,  or  15  characters  only. 

o General  systen  conventions  as  to  nanes  and 

puactuation  east  be  followed. 

FS  is  also  used  to  describe  the  foraat  of  any  non-NIPS 
data  file  to  be  processed  by  NIPS.  In  describing  the  foraat 
ot  the  file,  the  user  aust  be  aware  of  the  various 
restrictions  and  linitations  that  affect  non-NIPS 
processing.  These  include  a naxinua  sixe  of  1000  bytes  in 
a single  record  foraat,  the  required  presence  of  a non- 
repeating record  foraat  to  serve  as  a fixed  set,  the 
presence  of  one  or  nore  fields  in  each  record  foraat  to 
serve  as  record  13  fields,  the  presence  of  a single  field 
(up  to  10  bytes)  which  uniquely  identifies  each  record 
format.  Also,  the  general  restriction  which  apply  to  a 
stndari  NIPS  file  also  apply  to  a non-NIPS  file. 

3.2  File  Revision 

The  FI  coaponent  proviles  the  capability  to  revise  the 
format  in  which  data  is  stored  in  a NIPS  data  file.  This  is 
accomplished  by  the  comparison  of  the  FFT  describing  the 
file  ii  its  curreot  foraat  - to  the  FFT  describing  the  file 
ir  its  revised  format.  FR  will  generate,  as  a result  of  the 
comparison,  FH  logic  statenents  which  will  be  used  by  PM  to 
copy  selected  data  elenents  into  the  new  foraat. 

FP  processes  data  on  a fiall  basis  only.  It  will  perait 
th > addition,  deletion,  and  relocation  of  fields  as  well  as 
changes  to  their  storage  mode,  size,  and  naae.  Periodic 
sats  nay  be  deleted  oc  relocated.  They  nay  also  be  added. 
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b 'it  no  data  will  be  included,  as  a direct  result  of  FR,  in 
either  new  sets  or  fields.  FR  will  permit  fields  froa  any 
set  in  the  old  file  to  be  split  into  several  sets  in  the  new 
fils.  It  will  aot  perai:  fields  froa  aultiple  sets  in  the 
old  file  to  be  aerged  into  one  set  in  the  new  file.  There 
is  no  way  for  FR  to  logically  connect  the  subsets  of  two 
existing  sets.  The  FH  logic  stateaents  generated  aay  be 
aodified  by  the  user  to  suit  his  needs. 

The  only  liaitation  is  the  need,  on  the  part  of  the 
user,  to  reconcile  his  FH  logic  stateaents  and  any 
r-trievaLs,  outputs,  and  terainal  gueries  which  aight  be 
alfected  as  a result  of  file  revision. 

3.3  File  Maintenance 

This  component  provides  the  user  with  a broad  and 
flexible  capability  for  generating  and  aaintaining  data 
files.  Using  FH  coaponent  features,  the  user  aay  add, 
delete,  or  change  file  records,  periodic  sets  or  subsets, 
anl  variable  sets.  Also,  the  user  aay  aodify  or  change  file 
fields  and  nay  change  (increase  or  decrease)  the  volume  of 
data  associated  with  any  file  record.  If  indexing  is 
specified  for  the  file,  the  index  data  set  is  also 
maintained.  This  aaintenance  is  autoaatic  and  transparent 
to  the  user.  These  functions  aay  all  be  accoaplished  in 
parallel,  or  in  a single  pass  of  the  naster  data  file;  they 
nay  be  accoaplished  by  virtually  any  aixture  of  unsequenced 
input  transaction  foraats.  Multiple  file  aaintenance  passes 
aie  permitted  to  support  data  dependent  activities. 

Input  material  aay  be  records  which  are  either  fixed  or 
variable  in  length  and  aay  be  blocked  or  unblocked.  Storage 
media  for  input  aaterial  aay  be  any  supported  readable  aedia 
urlsr  tie  operating  systea. 

All  processing  is  controlled  by  logic  statements 
provided  by  the  user.  These  stateaents  aay  be  written  in 
eitaer  a ■ acro-lilce  programmer- oriented  language  (POOL)  or 
a high-level  procedural  English -like  language  (NFL)  which  is 
easy  to  learn  and  siaple  to  use,  yet  powerful  and  flexible 
enough  to  efficiently  accomplish  a wide  range  of  file 
aalntenaace  functions. « The  user  ^ay  perform  functions  using 
data  from  the  input  transaction,  the  naster  data  file 
record,  rfcords  froa  other  NIPS  files,  or  all  three.  The 
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Ordinary  Haintenance  (ON)  feature  of  Fh  permits  the  user  to 
write  logic  statements  containing  only  on  transaction 
descriptor  cards  which  can  perform  automatic  validation  of 
transaction  data  and  unconi itiona  1 updating  if  file  fields. 
The  ON  stateaents  can  be  coabined  with  POOL  statements  to 
provide  additional  user  flexibility.  All  input/output 
functions  are  performed  automatically  by  the  component; 
since  the  languages  are  indirect,  the  user  makes  his 
references  using  the  field  names  he  has  assigned  as 
meaningful  titles  if  data  elements.  The  languages  include 
instructions  that  permit  automatic  table  validation  or 
conversion  or  automatic  linkage  to  user- prov ided , special- 
purpose  subroutines.  The  indirect-addressing  capability, 
use  1 for  processing  field-initiated  correct.iois,  :s  another 
Pf1  reature. 

Tn  addition  to  maintenance  (or  generation)  of  a data 
fiLe,  tils  component  permits  the  user  to  ctearq  auxiliary 
output  files  simultaneously  with  the  maintenance  process. 
The  system  will  permit  the  generation  of  two  independent 
prin*  streams,  two  independent  punch  streams,  and  five 
auxiliary  sequentially-organized  output  streams  (tape  or 
direct  access  volumes)  in  parallel  with  the  priieo  processing 
t unc  *-ion. 

Generative  code  techniques  are  used  in  the  actual  data 
manipulation.  To  avoid  wasteful  regeneration,  the  system 
provides  a complete,  automatic  library  maintenance  function 
tor  '■he  user's  logic  statements.  Maintenance  execution, 
ther?fore,  may  consist  of  executina  prestored  logic 
statements,  compiling  logic  statements  and  Lbrary  updating, 
or  combinations  of  these  functions.  There  is  no  Limit  to 
the  number  of  different  statements  tha'  can  be  precompiled 
ini  retained  in  the  library,  or  to  the  number  of  : tatements 
that  can  be  used  in  a single  file  update  run. 

A data  file  may  be  maintained  as  an  ISAM,  SAN  or  VSAM 
lata  set.  Large  3 AH  files  may  be  segmented  into  volumes  of 
lata  records  containing  a range  of  record  Keys.  These  may 
-hen  be  updated  and  queried  individually  or  in  croups.  For 
a SAN  file  that  is  indexed,  volume  control  information  is 
provide!  so  that  queries  against  the  file  need  pass  only 
r hos^-  volumes  containing  thw  candidate  Records  appropriate 
*o  tie  query  instead  of  the  entire  data  file.  t 
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Other  coaponent  functions  provide  for  the  creation  of 
summaries,  run  logs  and/or  audit  trails  during  file 
proressiig.  These  functions  are  specified  by  the  user  and 
are  not  liaited  to  a set  of  predefined  systaa  capabilities. 
Thay  ara  as  siaple  or  coaplex  as  the  user's  requirements 
diet  ate. 

Liiitations  to  FH  inclide  the  following: 

o Haxiaua  size  of  transaction  recora  is  1,000 
characters. 

o A aaxiaua  of  24  logic  states  *»nts  may  be 
compiled  in  any  one  execution  of  WH. 

3.4  Retrieval  and  Sort  Processor 

The  RASP  coaponent,  primary  retriever  of  the  system,  is 
char  act eriz ed  by  its  voluainous,  batched -process ? nq 
capabilities.  Jsing  generative  code  techniques,  RASP 
in eludes  an  autoaatic  library  aai  ntenance  capability  whi  ch 
p-  caits  broad  utilization  of  the  standing  query.  Compile 
and- go  nodes  of  operation  perait  satisfaction  of  the  ad  hoc 
query  requireaent  and  coaplete  intermingling  of  co  pile---1 
go  and  standing  query  processing  in  a single  ;jo  b process  is 
peraitted. 

PASP  uses  a siaple  English- like , free-foraat 
coni ition/action  language  which  is  flexible  in  notation.  By 
specifying  the  retrieval  condition,  the  user  may  select 
specific  records  to  be  retrieved  from  the  data  file. 
Comparison  operators  provided  a re  the  normal  equal  to,  less 
thxn,  greater  than  and  between.  Ail  aay  be  preceded  by  the 
negative  operator  "not."  Boolean  connectors  are  permitted, 
as  are  up  to  eight  levels  of  nested  parentheses.  Two 
geographic  retrieval  operators  are  also  provided:  irregular 

area  and  circle  searcrh.  The  former  i s of  interest  in  that 
i proviias  ar ea-t o -arfti,  area-to- line,  line- to-1  ine,  and 
point-to- area  capabilities  and  is  not  constrained  to  convex 
area  definitions. 

"he  true  power  *of  the  processor,  however,  is  not 
d'.rectly  indicated  by  the  language.  The  scope  of  the 
p ocessor  is  wore  directly  related  to  its  ability  to  provide 
a. my  answer  sets,  each  of  5 if  fa  rent  control  or  sequence,  by 
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a single  pass  of  either  the  entire  data  file  or  only  those 
records  selected  as  possible  candidates  for  retrieval  by 
index  processing.  In  RASP,  the  sLaplest  qualification 

statement  is  called  a condition.  Satisfaction  of  the 
condition  assigns  the  output  of  the  file  recor  d (or  a 

selected  portion  of  the  file  record)  to  a temporary  file  for 
later  system  sequencing.  Since  the  user  aust  frequently 
output  information  froa  a file  record  in  several  sequences, 
each  condition  stateaent  aa  y have  several  associated  sort 
sti tenants.  Each  sort  stateaent  is  siaply  the  string  of 

fields  and/or  literals  upon  which  the  user  desires  to 
siqufnc*  the  at  swer  records.  Conditions  may  be  prestored 
* th  their  associated  sort  statements  on  the  query  library. 
E;n  ontcy  on  the  library  is  termed  a query  title.  Since 
tie  user  may  need  to  define  several  different  criteria  in 
s lasting  qualifying  records,  the  capability  to  associate 
d.  fferent  conditions  with  1 single  title  is  desirable.  Thus 
tr>  ? systei  permits  multiple  conditions  per  title  entry.  The 
total  number  of  conditions  and  sort  designations  may  be  as 
liige  as  255  per  title  entry.  Finally,  in  a single  file 
pass,  tie  system  will  accept  up  to  96  title  requests.  In 
sfort,  the  user  could  process  96  times  255  answer  sets  in  a 
single  file  pass.  This  limitation  is  consistent  with  the 
overall  system  philosophy  to  establish  limitations  on  a 
»ume  or  size  level  that  the  user  noraally  will  never 
r • ach . Index  processing  will  be  used  by  RASP  when  specified 
fcr  the  file  and  desired  by  the  user  at  run  tine.  PASP  will 
aralyze  queries  for  conditions  against  index  fields,  will 
tnei  exaaine  the  index  data  set,  and  obtain  a list  of 
records  which  contain  the  Appropriate  values  as  specified  in 
th*  queries.  Only  these  records,  rather  than  the  entire 
data  file,  will  be  exaalnei  in  detail. 

lost  retrievals  compare  field  contents  to  literals 
provided  in  the  query  statement.  The  system,  however, 
permits  restricted  comparison  of  field  contents,  one  field 
to  Another,  as  well  as  the  normal  literal  node.  Automatic 
conversion  of  comparison  literals  from  external  form  to  file 
fern  is  provided,  and  partial  field  notation  and/or  literal 
mashing  is  also  included. 

Froi  a programming  viewpoint,  the  result  of  the  RASP 
process  is  slightly  different  froa  that  sensed  by  the  using 
amlyst.  Although  RASP  gives  the  result  that  would  be 
ic  lie  v»  i by  redundantly  outputting  data  records  after  each 
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<j  u»  1 L f L oat  ion , ii  practice  this  redundant  output  is  avoided. 
Instead,  a technique  is  utilized  that  pernits  sequencing  of 
tha  resultant  answers  by  pointers  rather  than  physically 
sorting  the  data  records  thenselves.  Sequencing  tine 
i m pro  va  a ants  of  well  over  10  to  1 above  nornal  file  sort 
tines  can  thus  be  achieved.  In  applications  where  a 
retrieval  results  in  high  volunes  of  output,  this  attribute 
is  critical.  The  result  of  RASP  processing  is  a subset  of 
th;  interrogated  file;  after  processing  by  one  of  the  NIPS 
utility  prograns,  this  subset  nay  be  further  naintained, 
retrieved  fron,  and  used  as  input  to  update  another  data 
file. 

Additional  features  of  t.ha  oonponent  are: 

The  ability  to  nodify  retrieval  values  and  sort 
field  specifications  at  execution  tine  through  use 
of  the  skeleton  query  feature 

The  use  of  user-written  subroutines  to  qualify  data 
through  use  of  the  PUNCTION  operator 

The  passing  of  infornation  generated  by  user- 
written  subroutines  to  the  output  processors 
through  lie  of  sy3ten-provided  work  areas. 

Limitations  inposed  on  RASP  as  are  follows: 

o Haxinun  number  of  SORT  or  SELECT  pairs  per  IF 
or  PU  ETHER  statenent  is  20. 

o Haxinun  nunber  of  RIT  nanes  per  retrieval  is 

50. 

3 Haxinun  nunber  of  statenents  per  retrieval  is 
256. 

o Haxinun  nunber  of  subroutines  per  retrieval  is 

20. 

o Haxinun  nunber  of  clauses  per  statenent  is 

256. 

o Haxinun  nunber  of  retrievals  in  a single  file 
job  is  96. 
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o 

Maximum  number 
job  is  1. 

of 

retrievals 

in 

a merged 

file 

o 

Maximum  number 
is  10. 

of 

files  in  a 

merged  file 

jo  b 

0 

Maximum  number  of 
retrieval  is  400. 

field  or 

group  names 

per 

0 

Maximum  number 

of 

replaceabl  e 

var  iai>  les 

per 

retrieval  is  255. 

3 Maxima  number  of  cards  per  statement  is  27. 

o Maxiaum  number  of  characters  constituting  a 

list  of  multiple  data  values  in  a clause  is 
250  total  characters  in  the  list  plus  3 for 
each  value. 

a Haxiaua  number  of  operands  for  all  sowr 

statements  in  one  RASP  job  is  340. 

3.5  Output  Processor 

This  large  component  is  a report  generator.  As  such,  it 
includes  capabilities  for  formatting  extremely  complex  and 
lrng+hy  reports.  In  addition  to  the  normal  page  formatting 
c? pabilities,  the  OP  includes  a complete  logical 
conditioning  capability,  computational  capabilities, 
si  a a ar  i z at  ions,  totaling,  and  subtotaling.  In  addition  to 
th  e computational  capabilities,  one  and  two  dimensional  sum 
and  count  matrixes  may  be  specified.  It  is  a complete  and 
comprehensive  report  generation  system  driven  by  a master 
data  file  or  by  the  result  of  the  retrieval  process.  An 
irterfiLe  output  capability  allows  access  to  secondary  file 
records  during  the  output  process.  Data  elements  from  these 
secondary  files  may  be  combined  with  primary  file  data  to 
produce  a composite  report.  Records  are  selected  from 
secondary  files  by  means  of  pointers  within  the  primary 
file.  Dut put  say  be  in  print,  on  card,  disk,  or  tape,  or  it 
nay  be  any  combination  of  these.  Classification  cover 
pages,  downgrading  inforsation,  and  warning  indications  in 
the  case  of  classification  differences  are  automatically 
provided  by  the  component. 
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A flexible,  free  fore  user  language  is  provided.  As  in 
thi  other  components,  generative  code  techniques  are 

utilized  to  produce  a Report  Instruction  Table  (SIT). 

Therefore,  OP  includes  1 complete,  automatic  library 

capability.  Debug  nodes  assist  in  the  checkout  of  complex 

report  formats.  Implicit  and  explicit  data  conversion 
and/or  editing  is  also  included.  Any  nuaber  of  reports  nay 
be  published  froa  a file  or  RASP  output  in  a single  run. 

Maxinue  limitations  to  the  OP  coaponent  are  as  follows: 

o 40  reports  nay  be  structured  in  one  OP  run. 

o 10  data  files  nay  be  referenced  in  one  report. 

o 42  sets  aay  be  referenced  in  one  report. 

o 30  subroutines  may  be  specified  in  one  report. 

o 550  named  literals  aay  be  defined  within  one 

repoct. 

o 52  characters  is  the  aaximua  literal  size. 

o 8,192  bytes  constitute  a compiled  individual 

level  1 statement. 

o 5 retriever-generated  work  area  values  are 

used  per  set;  each  one  is  a full  word  in 
1 ea  gt  h. 
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3.6  Terninal  Processing 

The  TP  component  provides  MIPS  users  with  an  efficient, 
flaxibLa  leans  of  operating  in  a terninal  environment.  This 
component  provides  the  NIPS  interface  to  support  local  IBM 
3270  Information  Display  Systems,  local  or  remote  IBM  2260 
Display  Stations,  local  IBM  2250  Display  Units,  the  IBM  2741 
Co»  ■ uni  cation  Terminals,  and  the  IBM  1050  Data  Comunication 
System  (Dial-up).  The  number  of  devices  supported  is 
limited  only  by  the  hardware  configuration  and  the  loading 
ot  tha  system.  The  TP  coaponent  permits  utilization  of 
tlies<=  devices  in  a true  online  node,  allowing  different 
tists  to  be  initiated  froa  the  devices  without  scheduling 
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the  basics  through  the  normal  operating  system  job  strean. 
Th?  component  consists  of  two  major  functional  sections,  the 
TP  Monitor  and  the  TP  Supervisor. 

’’’ha  TP  Monitor  is  normally  core  resident  in  a single 
partition  or  region.  This  section  of  the  component  services 
lavice  requests,  perform?  input/output  queueing,  and 
controls  task  assignments.  Depending  on  user  environmental 
requiraments,  one  or  more  TP  Supervisor (s)  mav  reside  in 
machine  core.  Their  primary  function  is  simply  to  provide 
interface  for  TP  application  programs.  Dutput  generated  by 
tha  application  programs  is  made  availabla  to  the  terminal 
usar  for  paging  in  the  conversational  node. 

N IPS  provides  the  following  terminal  application 
prograss  or  components: 

a.  Quick  Inquiry  Processor  (QUIP)  is  designed  to  give 
the  user  a powerful  data  retrieval  and  display 
capability . 

b.  Source  Data  Automation  (SODAl  provides  the  user 
with  a means  of  executing  a precompiled  file 
laintenance  logic  statement  against  an  update 
transaction  entered  by  an  operator  at  an  online 
t erninal. 

c.  Inline  Source  Edit  (EDIT)  provides  the  ability  to 
enter,  manage  and  edit  NIPS  and  ALC  source  code 
language  statements  at  the  terminal  and  to  submit 
jobs  to  the  operating  system  for  batch  processing. 

d.  Utility  programs  provide  the  ability  to  send 

messages  and  data  between  terminals  and  to 
communicate  with  the  computer  operator. 

e.  FORMATTER  allows  the  user  to  define  a display 
format  for  a CRT  and  to  use  this  format  at  the 
terminal  to  enter  data.  This  data  can  then  be  used 
by  the  NIPS  application  programs  FMSODA,  QUIP, 
BLAST,  EDIT,  or  a user  written  program. 

The  QUIP  language  consists  of  a simplified  output 
lmguage  an  d a subset  of  the  RASP  language.  Although  QUIP 
wis  designed  primarily  for  terminal  application,  it  can  also 
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be  operated  in  the  batch  node  to  provide  a simple,  efficient 
tool  to  process  ad  hoc  queries,  then  executing  QUIP  as  a 
problei  program  in  the  online  terminal  environment,  it 
requires  a direct  access  resident  ISAM  NIPS  data  file  or  a 
direct  access  resident  SAM  data  file.  In  the  online 

enviroaieat,  QUIP  can  also  create  and  subsequently 
interrogate  a subfile  of  a NIPS  file.  A NIPS  data  file 
organized  as  either  ISAM,  SAM  or  VSAH  organization  (tape  or 
disk  resident)  is  acceptable  when  QUIP  is  executed  in  the 
uackground  environment.  where  possible,  QUIP  will  attempt 
to  lieit  the  nuabec  of  data  records  that  oust  be  exaained  in 
letail  through  the  use  of  file  indexing  in  the  sate  Banner 
is  PASP.  The  QUIP  language  allows  user  or  system  formatted 
> u t put  lines.  Dne  and  two  dimensional  sum  and  count 

matrixes  can  easily  be  specified  in  addition  to 

computational  operations.  An  additional  capability  allows 
the  tarainal  user  to  select  an  DP  RIT  from  the  user  library 
ind  display  pages  of  the  output  report  on  the  terminal. 
DUIP  provides  an  interfile  output  capability  in  the  same 
nann?r  as  OP.  Data  elements  extracted  from  secondary  files 
may  be  combined  with  primary  file  data  to  produce  a 
roapcsite  report.  QUIP  can  also  be  used  to  retrieve  and 
output  data  from  a non-NIPS  data  file.  Non-NIPS  processing 
can  be  performed  in  the  online  or  batch  environment  against 
either  SAM,  ISAM  or  VSAH  files.  Many  of  the  QUIP 

^abilities  available  for  processing  a NIPS  file  can  also 
tie  used  for  processing  a non-NIPS  file,  including  interfile 
iutput  processing. 

The  SODA  component  uses  a free-format  keyword  language 
consisting  of  control  statements  which  identify  files, 
records,  report  formats,  corrections,  and  disposition 
ictions.  Given  a file,  SODA  will  fetch  the  record 
identified  in  the  update  transaction,  and  provide  both  the 
record  and  the  transaction  to  the  library-stored  logic 
'.tatemeat  which  performs  the  required  edit  and  update 
function.  The  record  is  returned  to  the  data  file  in 

ipda+ed  form  under  operator  control.  The  user's  input 
transaction  is  validated  by  the  logic  statement  during 
xacution.  If  errors  are  detected,  immediate  notification 
tay  be  given  to  the  terminal  operator.  The  user  may  correct 
ndividual  lines  of  his  transaction,  using  the  standard  TP 
orrection  procedures  and  repeat  the  S3  DA  request.  The  user 
'ay  alternatively  enter  kmy-numbered  corrections  to 
individual  fields  and  repeat  the  request.  SODA  will 
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aaintdin  file  indexes,  if  present,  in  the  saee  Banner  as  PH. 
SODA  cimt  be  used  to  perfora  file  aaintenance  on  a VSAH 
data  base. 

Tha  EDIT  component  provides  the  capability  to  enter  and 
aaintain  source  language  stateaents  f roa  the  terainal.  The 
source  stateaents  nay  be  stored  on  a library  and  nodified 
froa  the  terainal.  The  aodified  sourca  stateaents  a ay  then 
be  edited  and  any  errors  reported  back  to  the  terainal 
operator.  when  errors  have  been  corrected,  a Job  Control 
Language  (JCL)  3trean  ay  ba  constructed  and  subaitted  to 
the  operating  systea  as  a background  job. 

The  NIPS  TP  utlity  prograas  include  the  capabilities  to 
dump  output  to  specified  printers,  route  output  to  other 
t'-rninals,  and  send  aessages  to  other  terainals  or  to  the 
computer  operator.  The  online  capability  is  also  provided 
t>  jcc?ss  a distribution  data  set  for  iaaediate  review  of 
outputs  previously  stored  is  the  result  of  batch  or  online 
t port  generation. 

The  FORMATTER  conponent  provides  the  user  capability  to 
specify  the  attributes  of  tha  CRT  display  Laage  using  the 
F i >F  HATTER  language.  The  specification  of  the  display  image 
i:  eludes  the  definitions  of  data  to  be  displayed  on  the  CRT, 
tha  definition  of  data  to  be  placed  on  the  IHQ  (Input 
Message  Queue)  records,  and  the  action  to  be  taken  after  the 
CP?  operator  enters  data  on  this  display.  The  user  display 
format  can  be  defined  and  stored  in  either  the  batch  or 
online  tode.  The  stored  foraat  is  utilized  in  the 
operational  phase.  The  CRT  operator  can  invoke  FORMATTER 
and  then  call  a foraat  by  the  user  assigned  nai».  FORHATTER 
wi  L L write  the  skeleton  inage  on  the  CRT  and  wait  for  the 
CFT  operator  to  key  data  into  the  defined  fields.  When  the 
operator  has  finished,  FORHATTER  will  create  the  IHQ  records 
according  to  the  user  specifications.  FORMATTER  will  then 
invoke  a NIPS  application  prograa  or  it  will  generate  a new 
format  display,  depending  on  the  specifications  in  the 
foraat  definition.  The  ca  {ability  to  specify  subsequent 
foraats  aad  application  prograas,  coabined  with  a capability 
to  pass  data  from  QUIP  and  SODA  to  a new  foraat,  provides 
extensive  flexibility  and  power  to  control  the  chaining  of 
online  applications. 
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3.7  ntility  Components 

A Large  collection  of  utility  support  programs  is 
provided  by  NIPS.  A data  validation/conversion- table 
generation  capability  which  a ssures  efficient  use  of  this 
important  data  processing  tool  is  provided.  Tables  formed 
by  the  system  are  modular  so  that  usage  on  minimum  core 
environments  may  be  achieved.  Table  sizes  may  effectively 
be  considered  jp  to  approximately  528,000  bytes  of 
arqu ment/f unction  pairs.  They  provide  simple,  effective 
utilization  of  validation  techniques  not  otherwise  possible. 
Maximum  combined  size  of  the  argument  and  function  is  256 
bytes, 

A utility  is  provided  to  allow  the  placing  of  load 
nodules,  created  by  compiling  user-written  subroutines,  on 
a NIPS  library.  The  subroutines  will  contain  the  linkage 
necessary  for  proper  utilization  by  NIPS.  The  subroutines 
nay  be  written  in  Basic  Assembler  Language,  COBOL,  FORTRAN, 
PL/1,  or  JOVIAL. 

Utilities  are  provided  to  convert  the  modes  of  NIPS 
files  from  ISAM  or  VS  AH  to  SAH  and  vice-versa.  Other 
utilities  are  available  to  specify  and  create  indexes  for 
existing  files,  and  to  transfer  index  data  sets  from  disk  to 
tape  and  vice-versa.  Utilities  are  also  available  to 
analyze  text  for  keyword  selection  and  to  create  and 
maintain  keyword  dictionaries  and  tables.  Another  accepts 
a ratriaval  answer  file  and  converts  it  to  a data  file 
containing  all  of  the  properties  of  a NIPS  master  file. 
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Section  4 


SYSTEM  FEATURES 


To  simplify  the  training  of  nonprogramming  oriented 
users,  the  systea  aa  kes  extensive  use  of  the  stored 
procedure  and  cataloging  capability  of  the  operating  system. 
This  tesults  in  effectively  eliminating  the  requirement  for 
the  typical  user  to  code  JCL  streams  to  control  his  job. 
The  skilled  programmer  may,  however,  continue  to  use  fully 
th e flexibilities  provided  by  the  operating  system. 

Modularity  of  programming  ensures  simplified  maintenance 
and  error  correction  in  the  operating  software.  Relatively 
unique  code  generation  techniques  ensure  ease  of 
modification  in  the  user  language  areas,  if  needed. 

All  user- genera  ted  material  required  to  support  a data 
file  is  contained  as  part  of  the  data  file  or  user  library. 
The  FFT,  PM  logic  statements,  and  data  records  are  all  a 
part  of  the  data  file  itself.  All  conversion  tables, 
subroutines,  RASP  queries,  QUIP  queries,  and  3P  RITs  can  be 
on  a single  user  library.  The  user's  source  material  nay 
reside  in  the  same  library  or  in  a separate  library.  By 
causing  the  library  to  occupy  a direct  access  device  with 
the  data  set,  a notable  degree  of  file  transportability  is 
achieved.  A system  user  may  effectively  move  a single  disk 
pack  (data  volume  permitting)  to  another  system  operating 
with  NIPS  and  be  assured  that  he  has  all  the  materials 
necessary  to  maintain,  retrieve,  or  display  data  from  his 
file. 

rila  analysis  and  run  optimization  statistics  nay  be 
produced  by  FM,  RASP,  QiJIP  and  DP  upon  demand.  File 
analysis  statistics  assist  a user  in  redesigning  a file  and 
selecting  proper  data  elements  for  secondary  indexing.  Run 
optimization  statistics  assist  in  tuning  production  jobs  to 
run  most  efficiently. 

'‘leven  volumes  of  user- oriented  documentation  cover  the 
system  components,  error  codes,  procedures,  techniques  and 
general  fLle  concepts.  Program  Specification  Manuals  are 
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iviilabls  to  assist  installation  systea  prograaners  in 
understanding  systea  capabilities. 
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Section  5 

OPERATING  SISTER  CONSIDER  AT  IDN  S 


MIPS  will  operate  under  fire  operating  systea 
configurations: 

PCP  Priaary  Control  Progran.  The  standard 

operating  systea  which  processes  one  jab 
at  a tine  in  sequence. 


HPT  Bultiprograaaing  with  a fixed  number  of 

tasks.  A partitioned  core  systea 
allowing  op  to  four  jobs  to  operate 
concurrently  in  independent  fixed-size 
part  it  ions. 


DVT  Bultiprograaaing  with  a variable  number 

of  tasks.  A regional  core  system 
allowing  up  to  15  jobs  to  operate 
concurrently  in  va  riabie-sl  ze  regions. 


IS  1 Operating  Systea/Virtual  Storage  1.  A 

virtual  storage  systea  which  can  perform 
15  different  tasks  concurrently. 


IS 2 Operating  Systen/lirtual  Storage  2.  A 

virtual  storage  system  which  can  perform 
63  diffsrent  tasks  concurrently. 

NIPS  is  not  restricted  to  any  one  level  of  the  operatin 
systea  and  it  will  use  subsequent  releases  as  they  becom 
available.  Hultiprogra suing  capabilities  of  the  operating 
systea  perait  aultiple  jobs  to  operate  concurrently  in 
Lnlapendait  partitions,  regions  or  virtual  storage.  The 
data  aanageaent  facilities  of  the  operating  system  will 
handle  all  systea  and  user  data  storage.  NIPS  data  files 
can  be  organized  under  ISAH  for  lirect  access  device  files, 
oi  SAB  for  tape  >c  direct  access  files,  or  under  vsam  for 
direct  access  files  on  the  S/310  operating  under  V5  1 or  VS 2 . 
Data  file  indexes,  where  applicable,  are  organized  under  the 
Basic  Direct  Access  Method  (BDAH)  and  reside  on  a direct 
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i::>ss  device.  The  various  system  libraries  will  be  store! 
using  Basic  Partitioned  Access  Method  ( BP  AH) . The  Basic 
Graphic  Prograaaing  Services  of  the  operating  system  are 
used  for  the  TP  component  that  services  the  local  IBM  2250 
and  2260  display  terminals.  The  Basic  Telecommun ications 
Access  Method  (BT  AM)  is  required  for  remote  device  support 
and  for  local  IBM  3 270  Information  Display  Systems. 

In  addition  to  the  basic  operating  system,  the  following 
Bust  be  included  at  systes  generation  tiae: 

a.  Programs 

1.  Assembler  - E level 

2.  Linkage  Editor 

3.  Sort 

h.  Libraries 

1.  HACLXB  - Macro  Library 

2.  SORTLIB  - Sort  Library 

c.  Data  Management  Access  Methods 

1.  Sequential  Access  Method 

2.  Index  Sequential  Access  Method 

3.  Basic  Direct  Access  Method 

4.  Basic  Partitioned  Access  Method 

5.  Basic  Graphics  Programming  Services  (needed 
only  for  terminal  processing  support) 

6.  Basic  r elecoani nication  Access  Method 
(needed  only  for  remote  terminal  processing 
support ) 

7.  Virtual  Storage  Access  Method 
(available  only  on  an  S/370  with  VS1 
or  VS2) 


j 
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Section  6 

HARDiARE  CONSIDERATIONS 


( 


NIPS  has  been  designed  and  prog  tanned  for  an  IBH  System 
360  Model  SOU  (256K  core  size).  It  nill  also  operate  on  a 
Modal  4 0 H and  larger  nodela  of  the  Systen  360  line  and  Model 
135  and  larger  nodels  of  the  Systen  370  line.  witho.it 
online  terminals,  it  will  operate  on  a 128K  core  size 
machine,  however,  experience  has  shown  that  the  H core  is 
tha  nlniaum  for  conplex  applications  on  nonvirtual  storage 
systens.  NIPS  can  use  nagnetic  tapes,  direct  access 
devices,  card  reader/punches,  online  printers,  a console 
typewriter,  and  IBH  2260,  2265,  2250,  3277,  3275,  1050,  and 
2741  teninals 

A minimum  configuration  could  include  three  IBM  23!' 
dish  units,  (although  an  IBH  2314  or  3330  disk  storage  unit 
Is  considered  highly  desirable)  a card  reader,  and  an  on- 
line printer.  Tape  requirements  are  related  to  the  user's 
requireaents  and  range  fros  none  to  a quantity  sufficient  to 
perfori  the  largest  sort  the  user  nay  require.  Disk  sorting 
is  used  to  the  capacity  of  the  direct  access  devices 
available  to  the  systen. 

The  systen  will  service  a number  of  IBM  2848  display 
control  units,  each  of  which  will  support  one  1053  printer 
and  eight  local  2260  terninals  for  online  processing.  Up  to 
32  IBH  3277  display  stations  nay  be  attached  to  the  syste^ 
via  each  3275,  and  3272  control  unit.  An  unlimited  number 
of  local  2250  terninals  are  supported  under  these 
configurations: 

a.  2250  -1  Each  terninal  has  its  own  control  unit. 

m 

b.  2250  -3  Up  to  four  terninals  for  each  2840-2 

control  unit. 

Peiote  IBH  3277,  3275,  2260,  2265,  1050,  or  2741 

configurations  nust  include  appropriate  communications 
facilities  and  21/BI  data  adapter  or  transnission  control 
uni ts . 
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Section  7 

DEVELOPMENT  AND  MAINTENANCE 


The  NIPS  data  eanageaent  systei  is  managed  by  the 
Defense  Cone  unicat  ions  Agency  to  aeet  the  requirements  of 
the  National  Military  Connand  Systea.  In  the  interests  of 
economy  and  standardization  NIPS  is  provid°d  on  a fully 
supported  basis  to  other  Departaent  of  Defense 
organizations.  Development  and  aaintenance  activities  ace 
directed  ir  consideration  of  the  needs  of  this  fully 
supported  NIPS  user  coaaunity. 

The  requirements  of  the  command  and  control  and 

intelligence  coaaunities  call  for  a very  high  level  of 
reliability.  The  goal  of  NIPS  aaintenance  is  to  insure 
efficient  performance  to  meet  all  capabilities  specified  in 
t ;e  user  manual  series.  Designated  fully  supported  users 
a a encouraged  to  subait  fully  docuaented  Discrepancy/Change 
P ports  (DCP ) for  discrepancies  between  systea  operation  and 
documented  performance  specifications.  Each  discrepancy  is 
acknowledged  with  corrective  action  for  programs, 
documentation  or  user  application.  All  NIPS  users  enjoy  the 
benefits  of  a aaintenance  prograa  based  on  a wide  variety  of 
applications.  ] 

t 

I 

New  developments  and  the  results  of  systea  aaintenance 
ari  provided  to  NIPS  users  in  the  fora  of  tested  system 
releases.  Releases  are  scheduled  depending  on  the 
magnitude  of  the  changes  included  in  the  release,  aajor 
Department  of  Defense  activities  and  avoidance  of  concurrent 
implementation  with  a new  operating  systea  release. 

Emergency  fixes  are  provided  immediately,  if  possible.  j 

An  aggressive  enhancement  prograa  has  been  underway  for 
several  years  and  is  planned  to  continue.  Major  areas 
toward  which  developnent  Activities  have  been  directed  are 
as  follows: 

a.  Efficiency.  Continuing  efforts  will  be  directed 
toward  optiaizing  use  of  coaputer  resources  for  the 
aultiprogr aaaing  environaent. 
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b.  Interfile  operations.  Multiple  file  reference  both 
during  update  and  output  will  support  applications 
integration. 

c.  Transaction  Management.  Improved  capabilities  to 

route  and  edit  transactions  entering  and  leaving  an 
installation  will  reduce  manual  transaction 

handling  and  point  toward  real-time  information 
handling. 

d.  Language  Standardization.  Consistent  use  of  1 

punctuation  and  instruction  forms  will  reduce  usee 

errors  and  speed  training. 

p.  Extended  OnLine  Operations.  Continued  expansion  of  < 

remote  terminal  services  will  place  the  ultimate 
information  user  in  closer  contact  with  his 
information. 

f.  Statistics.  Extensive  information  will  be 

available  about  the  operation  of  applications  to 
enable  users  to  tune  applications  for  greater 
efficiency . 

g.  Capability  improvement.  A continuing  effort  is 
underway  to  make  the  system  easier  to  use  and 
extend  the  range  of  capabilities  available  to  the 
user. 

h.  Documentation.  Complete  and  easily  used 
documentation  is  the  hey  to  effective  use  of  NIPS. 

Constant  attention  is  given  to  current  maintenance 
and  improvement  to  users  manuals  and  other  system 
documentat ion. 

mh»  enhancement  program  is  managed  so  as  to  provide 
cons ‘an  tiy  improving  capability  with  minimum  disruption  to 
the  operation  of  current  user  applications.  The  following 
are  major  criteria  applied  to  the  design  and  implementation 
of  enhancements. 

a.  Incorporate  capabilities  so  that  each  nodule  will 
perform  its  basic  operation  in  a 90k  byte  partition 
or  region.  New  capability  which  if  used  causes  an 
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application  to  axceal  this  limitation  must  be 
optional. 

b.  Maintain  dynamic  r ora  utilization  capabilities  so 
that  NIPS  applications  will  efficiently  use 
additional  core,  if  available. 

c.  Maintain  the  transportability  and  transferability 
of  NIPS  applications  between  NIPS  using 
i nstallati ons. 

d.  Maintain  standard  operating  systee  conventions. 

e.  maintain  an  efficiency  balance  between  update  and 
retrie val. 

f.  Minimize  the  degree  to  which  an  installation  can 
becowe  I/O  or  cowpute  bound. 

g.  Incorporate  only  those  capabilities  that  are 

documented  for  easy  understanding  by  the  average 
user  and  foolproof  in  operation. 

h.  Provide  a full  range  of  diagnostic,  debugging,  and 
tuning  tools  to  the  user. 

i.  Maintain  a high  degree  of  generalization  while 

incorporating  optional  specialized  capabilities 

which  optimize  the  use  of  HIPS  for  Department  of 
Defense  command  and  control  and  intelligence 
f unctions. 

j.  Provide  for  continued  maintainability  so  as  to 
insure  a very  high  lsvel  of  reliability  during  the 
development  and  operation  of  applications. 


ENEPAL 

k. 


OESCBIPTIOM 


.pbisticatad  capabilities  SO  that: 


applications 


incorporate  new  so 
, Ch.»9«  to  ..istinq 

Bini»i*ed* 

^abilities  are 

ace  available. 

nA*rrt  fletJ  nit  

o 


are 


S iaple  basic  SIPS  cal 
standard  default  option! 


not  lost 


30 


CENEPAL  DESCRIPTION 


Section  8 

SOHHARY 


NIPS  exemplifies  the  heavy-duty  file  processor  which  has 
been  the  Mainstay  of  the  Department  of  Defense  cnnand  and 
control  and  intelligence  data  handling.  In  its  current 
version,  this  system  incorporates  a comprehensive  online 
capability  which  further  enhances  its  ada ntability  to 
today's  processing  requirements.  The  evolutionary  approach 
continues  to  be  the  foundation  of  the  system's  development. 
The  validity  of  this  approach  is  increasingly  apparent  as 
the  number  of  users  and  applications  increases.  For 
application  areas  with  high-volume  and  large  file-processing 
requirements,  NIPS  provides  a convenient,  efficient,  and 
flexible  lethod  of  solving  the  data  handling  problems  in  the 
IB1  System  360  and  System  370  hardware  and  software 
envi ronment. 


DISTRIBUTION 


CCTC  CODES 


COPIES 


C124  (Reference)  2 

C124  (Record  Copy)  

C240  (COR  for  CSC)  2 0 

C30  0 1 

C310 1 

C311 1 

C312 I 

C313 1 

C314  1 

C315 1 

C31b 1 

C317 1 

C32o  ('i  raining)  

C321 1 

C322  

C32  3 1 

C324  1 

C325  1 

C340  

C341  (maintenance  contractor)  

C341  (Stocn)  

C700  1 

C702  1 

C703  

C705  1 

C710  (Vec.i  Ser  Support) 

C720  

C7  30  


1 


DC A CODES 


C100 1 

C110 1 

C20-3 1 

C53U 1 

C600  1 
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COPIES 


Director  of  Administrative  Services,  Office  of  the  Joint 
Chiefs  of  Staff 

Attn:  Chief,  Personnel  Division,  Room  2A944,  The  Pentagon 


Washington,  D.C.  20301  1 

Director  for  Personnel,  J-l,  Office  of  the  Joint  Chiefs  of 
Staff,  Attn:  Chief,  Data  Service  Office,  Room  1B738C, 

The  Pentagon,  Washington,  D.C.  20301  1 

Director  for  Operations,  J-3,  Office  of  the  Joint  Chiefs 
Staff,  Attn:  Chief,  Data  Processing  Division,  Room  2C869, 

Tne  Pentagon,  Washington,  D.C.  20301  1 

Director  for  Operations,  J-3,  Office  of  the  Joint  Chiefs 
of  Staff,  ;vttn:  P & AD,  Room  2B870,  The  Pentagon, 

Washington,  D.C.  20301  1 

Director  for  Operations,  J-3,  Office  of  the  Joint  Chiefs 
of  Staff,  Attn:  Deputy  Director  for  Operations 
(Reconnaisance  and  Electronic  Warfare)  Room  2D921, 

The  Pentagon,  V7ashington,  D.C.  20301  1 

Director  for  Logistics,  J-4,  Office  of  the  Joint  Chiefs 
of  Staff,  Room  2E828,  The  Pentagon,  Washington,  D.C. 

20301  1 

Chief,  Studies  Analysis  and  Gaming  Agency,  Attn:  Chief, 

Force  Analysis  Branch,  Room  1D928A,  The  Pentagon, 

Washington,  D.C.  20301  1 

Automatic  Data  Processing,  Liaison  Office,  national 
Military  Command  Center,  Room  2D901A,  The  Pentagon, 
Washington,  D.C.  20301  1 

Automatic  Data  Processing  Division 
Supreme  Headquarters  Allied  Powers,  Europe 

Attn:  SA  & P Branch,  APO  New  York  09055  1 

Defense  Civil  Preparedness  Agency,  Computer  Systems 
Division,  Room  3D317,  The  Pentagon,  Washington,  D.C. 

20301  1 

Director,  Defense  Communications  Agency,  Office  bf  MEECN 
System  Engineering,  Attn:  Code  960T,  Washington,  D.C. 

20301  1 

Director,  Defense  Communications  Engineering  Center, 

Hybrid  Simulation  Facility,  1860  Wiehle  Avenue,  Reston, 

VA  22070'* 1 


t 


1 


1 
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xrrwjAi.  conus 


Commander , Joint  Technical  Support  Activity 
Attn:  Chief,  Software  Operations  Division 

1860  Wi«.hle  Avenue,  Reston , VA  22070 1 

Director,  Defense  Intelligence  Agency 
Attn:  DS  - 5C2 

Washington,  DC  20301 ■ 5 

Commander-in-Chief , Pacific,  Attn:  J6331,  FPO  San 

Francisco,  96610 1 

Commander -in-Chief , F.urope,  Attn:  Chief,  EL’COM  ADP  Systems 
Office  (ECADD  APO  New  York  C9128 y 

Command*.  r-in-Chief,  US  Army  Europe  and  Seventh  Army 

Attn:  ODCS , OPS  APO  New  York  09403 ! 

Commanding  General,  U3  Army  Forces  Command,  Attn:  Data 

Support  Division,  Building  206,  Fort  McPherson,  GA  30303 1 

Commander,  Fleet  Intelligence  Center,  Europe,  Box  18, 

Naval  Air  Station,  Jacksonville,  FL  32212 1 

Commanding  Officer,  Naval  Air  Engineering  Center,  Ground 
Support  Equipment  Department,  SE  314,  Building  7G-1, 

Philadelphia,  PA  19112 ^ 

Commanding  Officer,  Naval  Security  Group  Command, 

3801  Nebraska  Avenue,  NW,  Attn:  GP22,  Washington,  DC 

203  )0 1 

Commanding  Officer,  Navy  Ships  Parts  Control  Center 

Attn:  Code  712,  Meehan icsburg , PA  17055 1 

Headquarters,  US  Marine  Corps,  Attn:  System  Design  and 
Programming  Section  (MC-JSMD-7)  Washington,  DC  20300 1 

Commanding  Officer,  US  Army  Forces  Command  Intelligence 

Center,  Attn:  AFIC-l’D,  Fort  Bragg,  NC  20307 ! 

Commander , US  Army  Foreign  Science  and  Technology  Center 

Attn:  AMXSJ-CS , 220  Seventh  Street,  NE,  , 

Ch.irlottsvillo,  VA  22212 j 

34 

% 

t 


EXTliF'.'.'Al 


COPIES 


f 

I 


Commanding  Officer,  US  Army  Security  Agency,  Command 
Data  Systems  Activity  (CDSA)  Arlington  Hall  Station 
Arlington,  VA  222.1.2 


Commanding  Officer,  US  Army  Security  Agency  Field 

Station  - Augsburg,  Attn:  IAEADP,  APO  New  York  09458 1 

Commander,  Fleet  Intelligence  Center,  Atlantic, 

Attn:  DPS,  Norfolk,  VA  23511 1 

Commander,  Fleet  Intelligence  Center,  Pacific,  Box  127' 

FPO  San  Francisco,  96610 1 

Air  Force  Operations  Center,  Attn:  Systems  Division 

(XOOCSC)  Washington,  DC  20301 1 

Commander , Armed  Forces  Air  Intelligence  Training  Center, 

Attn:  TINI-MIT,  Lowry  AFB , CO  80230 1 

Commander,  Air  Force  Data  Services  Center,  Attn:  Director 
of  System  Support,  Washington,  DC  20330 1 

Commandcr-in-Chief,  US  Air  Forces  in  Europe,  ATTN:  ACDI 

APO  New  York  09332 1 

Commander,  USAF  Tactical  Air  Command,  Langley  AFB, 

VA  23665 1 

Commander,  Space  and  Missile  Test  Center,  Attn:  (ROCA) 

Building  7000,  Vnndenberg,  AFB,  CA  93437 1 

Naval  Air  Systems  Command,  Naval  Air  Station, 

Code  13000,  Jacksonville,  FL  32212 1 

Commanding  General,  US  Army  Computer  Systems  Command, 

Attn:  Support  Operations  Directorate,  Fort  Belvoir, 

VA  1 

Defense  Documentation  Center,  Cameron  Station, 

Alexandria,  VA  22314 - 12 

^ TOTAL  171 
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